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(57) The present invention provides a system and 
method for communicating data between a source ap- 
plication process and one or more destination applica- 
tion processes. This system and method perform con- 
version and routing functions which require only a single 
conversion of all outbound transmissions regardless of 
the variety of destinations, and only a single conversion 
of all inbound transmissions regardless of the variety of 
sources. The functions also enable changes, additions, 
and deletions of sources and destinations of transmis- 
sions to be made without modification of a source or 
destination application process and without taking a 
source or destination application process off-line. The 
functions further enable this system and method to be 



implemented in virtually any enterprise architecture 
without requiring that each processing system of the ar- 
chitecture be custom built. These conversion and rout- 
ing functions are performed by first receiving data to be 
transmitted in a source format from a source application. 
This data are then converted from the source format to 
a standard format. Next, one or more destinations are 
identified in a database using a transaction type corre- 
sponding to the data and/or the address of the source 
application. After identifying the one or more destina- 
tions, a copy of the data is transmitted to each and the 
data are then converted from the standard format to a 
destination format. Lastly, this converted data are 
passed to the destination process. 
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Description 

Background Of The Invention 

[0001] This invention relates to systems and methods s 
for communicating data. More particularly, this invention 
relates to systems and methods for communicating data 
between a source process and one or more destination 
processes, in which data are converted from a source 
format to a standard format, the data are routed from 10 
the source process to the one or more destination proc- 
esses, the data are converted from the standard format 
to a destination format for each destination process, and 
receipt of the data is verified at each destination proc- 
ess. '5 
[0002] Integrated processing architectures in which a 
variety of processing systems communicate with each 
other over a communication network are widely used in 
commerce. Because of the different communication re- 
quirements of each processing system in such architec- 20 
tures, it is frequently necessary to incorporate multiple 
translation processes into each transmitting or receiving 
processing system to translate outgoing or incoming da- 
ta. This necessity becomes particularly burdensome as 
the variety of source transmission formats or destination 2s 
transmission formats increases for any processing sys- 
tem. For example, in an' architecture comprising four for- 
mat-unique processing systems A, B, C, and D in which 
A transmits data to all of B, C, and D, and D receives 
data from all of A, B, and C, both A and D would need 30 
to have three translators each to respectively convert 
the transmissions to and from the necessary formats. 
[0003] Another disadvantage with these architectures 
is that changing, adding, and/or removing sources and/ 
or destinations for data transmissions is difficult be- 3S 
cause the application processes that generate each 
copy of the transmissions generated and that perform 
the corresponding translations, must be modified. 
These modifications may be particularly problematic to 
the extent that they introduce potential flaws into the ap- 40 
plication processes and that they require the modified 
applications to be taken off-line while being altered. 
[0004] A further disadvantage with these architec- 
tures is that each architecture is usually unique from en- 
terprise to enterprise because of the unique needs and 45 
desires of the enterprises, and, therefore, each archi- 
tecture must be custom built at significant expense in 
both time and money. For example, in the architecture 
comprising processing systems A, B, C, and D used as 
an example above, each processing system would have so 
to be custom built to incorporate the required translators 
for each of the other systems. Likewise, in another sim- 
ilar architecture comprising processing systems A, B, C, 
D, and E, each processing system would also have to 
be custom built to incorporate the required translators ss 
for each of the other systems although only one addi- 
tional system (i.e., system E) makes this architecture dif- 
ferent from the first architecture. 



[0005] In view of the foregoing, it would be desirable 
to be able to provide a system and method for commu- 
nicating data between a source process and one or 
more destination processes which do not require a sep- 
arate translator on each source or destination process- 
ing system for each data format type to be transmitted 
or received, respectively. 

[0006] It would be also desirable to be able to provide 
a system and method for communicating data between 
a source process and one or more destination process- 
es which do not require an application process to be 
modified to change, add. or remove a source or desti- 
nation of a data transmission. 

[0007] It would be further desirable to be able to pro- 
vide a system and method for communicating data be- 
tween a source process and one or more destination 
processes which do not require an application process 
to be taken off-line to change, add, or remove a source 
or destination of a data transmission. 
[0008] It would be still further desirable to be able to 
provide a system and method for communicating data 
between a source process and one or more destination 
processes that can be implemented in virtually any en- 
terprise architecture without requiring that each 
processing system of the architecture be custom built. 

Summary Of The Invention 

[0009] The invention is defined by the appended 
claims to which reference is hereby directed. Embodi- 
ments of the invention may have the advantage that a 
system and method for communicating data between a 
source process and one or more destination processes 
does not require a separate translator on each source 
or destination processing system for each data format 
type to be transmitted or received, respectively. 
[0010] Embodiments of the invention may have the 
further advantage that a system and method for com- 
municating data between a source process and one or 
more destination processes does not require an appli- 
cation process to be modified to change, add, or remove 
a source or destination of a data transmission. 
[0011] Embodiments of the invention may have the 
advantage that a system and method for communication 
data between a source process and one or more desti- 
nation processes does not require an application proc- 
ess to be taken off-line to change, add, or remove a 
source or destination of a data transmission. 
[0012] Embodiment of the invention may have the still 
further advantage that a system and method for com- 
municating data processes that can be implemented in 
virtually any enterprise architecture without requiring 
that each processing system of the architecture be cus- 
tom built. 

[001 3] In accordance with a preferred mbodiment of 
the present invention, a system and method for commu- 
nication data between a source application process and 
one or more destination application processes, are pro- 
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vided More particularly, the system and method of the 
present invention perform uniform conversion and rout- 
ing functions which require only a single conversion of 
all outbound data transmissions regardless of the vari- 
ety of data sourc s. Through these function, the system s 
and method of the present invention enable changes, 
additions and deletions of sources and destinations of 
data transmissions to be made without modification of 
a source or destination application process and without 
taking a source or destination application process off- io 
line Also, by using uniform conversion and routing func- 
tions this system and method may be implemented in 
virtually any enterprise architecture without requiring 
that each processing system of the architecture be cus- ^ 
torn built. 

[0014] These conversion and routing functions are 
performed by first receiving, in a source format and from 
a source application, data to be transmitted. These data 
are then converted from the source format to a standard 
format Next, one or more destinations are identified 20 
based upon a transaction type corresponding to the data 
to be transmitted and/or the address of the source ap- 
plication. After identifying the one or more destinations, 
a copy of the data is then transmitted to each. Upon re- 
ceipt of each copy of the data at the corresponding des- 25 
tination the data are then converted from the standard 
format to a destination format. Lastly these converted 
data are passed to a corresponding destination process. 
[0015] In preferred embodiments of the system and 
method of the present invention, a receipt acknowledg- 
ment function is also performed. This function produces 
a receipt acknowledgment when transmitted data are 
received at a destination process. If this acknowledg- 
ment is not received at a source process prior to the oc- 
currence of a given number of other transmission at- 35 
tempts or a given time period, an error notification will 
be generated. This error notification may then trigger an 
automated process that handles the error or alert a user 
to the error condition so that manual handling of the error ^ 
can be accomplished. 

Rrief Description Of Th e Drawings 

[0016] The above and other objects and advantages 
of the invention will be apparent upon consideration of « 
the following detailed description, taken in conjunction 
with the accompanying drawings, in which like reference 
characters refer to like parts throughout, and in which: 

FIG. 1 is a block diagram of an integrated process- so 
ing architecture in which a communication system 
in accordance with the present invention may be im- 
plemented; 

FIG. 2 is a block diagram of processing system im- 
plementing a portion of a communication system in ss 
accordance with the present invention: 
FIG. 3 is a flowdiagram illustrating an outbound bro- 
ker process for sending data and verifying data 



transmissions in a communication system in ac- 
cordance with the present invention: 
FIG. 4 is a flow diagram illustrating a process for 
converting data to be sent in a communication sys- 
tem in accordance with the present invention; 
FIG. 5 is a flow diagram illustrating a process for 
transmitting data in a communication system in ac- 
cordance with the present invention: 
FIG. 6 is a flow diagram illustrating an inbound bro- 
ker process for receiving data in a communication 
system in accordance with the present invention: 
FIG. 7 is a flow diagram illustrating a process for 
verifying and acknowledging the integrity of data re- 
ceived in a communication system in accordance 
with the present invention: 

FIG. 8 is a flow diagram illustrating a process for 
converting received data in a communication sys- 
tem in accordance with the present invention: and 
FIG. 9 is a flow diagram illustrating a management 
system process for setting up a communication sys- 
tem in accordance with the present invention. 

Detailed Description Of The Invention 

[0017] The present invention provides a system and 
method for communicating data between multiple appli- 
cation processes that are being executed on one or 
more processing systems connected to a communica- 
tion network. In communicating data between these ap- 
plication processes, the system and method may per- 
form conversion, routing, and receipt verification func- 
tions. Preferably, these functions are performed by in- 
bound and outbound broker processes that are each ex- 
ecuted on the one or more processing systems. In pre- 
ferred embodiments of the present invention, each of 
these functions may be configured and controlled 
through a user interface on a management system that 
is also connected to the communication network. 
[0018] To facilitate data being communicated be- 
tween application processes that require the data to be 
in different formats, the conversion function of the 
present invention first converts the data from a source 
format to a standard format, and then converts the data 
from the standard format to a destination format. The 
first conversion is preferably performed by an outbound 
broker process that is executed on a source processing 
system, and the second conversion is preferably per- 
formed by an inbound broker process that is executed 
on a destination processing system. In performing the 
first conversion, the outbound broker process first iden- 
tifies the type of data being transmitted Based upon the 
data type identified, the broker process then retrieves 
formatting rules which dictate how the source data are 
to be converted. Finally, the data are pn.scd from the 
source format and formatted into the standard format 
according to the formatting rules. SimiUr y m perform- 
ing the second conversion, the inbound ::■ :>et process 
first identifies the type of data received r> «-?d upon the 
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data type identified, the broker process then retrieves 
formatting rules which dictate how the standardized da- 
ta are to be converted. Finally, the data are parsed from 
the standard format and formatted into the destination 
format according to the formatting rules. 
[0019] Prior to transmission, the outbound broker 
process also performs a routing function on the data to 
be transmitted. This routing function eliminates any 
need for a transmitting application process to identify a 
destination process for to-be-transmitted data, allows 
any number of destination processes to receive trans- 
mitted data, and enables application processes to be 
easily added and removed as destinations for transmit- 
ted data. In performing this function, the data type of 
data to be transmitted is first determined. One or more 
destination processes for the data are then identified 
from a list in a configuration database that is accessible 
to the outbound broker process. This identification may 
be performed, for example, by determining which des- 
tination processes listed in the database are indicated 
as receiving data of the determined data type and/or da- 
ta from the source application process associated with 
this outbound broker process. Finally, for each of the 
identified destinations, a copy of the to-be-transmitted 
data is constructed and information identifying the cor- 
responding destination process is added to each copy 
. of the to-be-transmitted data so that the data may then 
be transmitted to each destination. 
[0020] Through these conversion and routing func- 
tions, the system and method of the present invention 
can achieve the aforementioned objects. For example, 
only a single translator is required for each source or 
destination application process because the conversion 
process is always performing the same conversion re- 
gardless of where data is going to or coming from (i.e., 
the conversion process always converts data from a 
source format to a standard format or converts data from 
a standard format to a destination format). As another 
example, through the combination of the conversion 
function and the routing function, changes, additions, 
and deletions of sources and destinations of data trans- 
missions can be made without the modification or shut- 
ting-down of an application process because the same 
conversion function is always performed for all data 
transmissions senior received, and because the routing 
function refers to a database to retrieve the parameters 
for each particular transmission or reception. As still an- 
other example, the system and method of the present 
invention can be implemented in virtually any enterprise 
architecture without requiring that each processing sys- 
tem of the architecture be custom built because the con- 
version process is only dependent upon the application 
process to which it is being applied, and because the 
routing function relies on a database for controlling its 
operation that may be implemented separately from the 
corresponding application process. 
[0021] The receipt verification function of the system 
and method of the present invention monitors whether 



6 

data transmitted from a source application process to a 
. destination application process by way of an outbound 
broker process and an inbound broker process is re- 
ceived by the destination application process. If the re- 
s ceipt verification function cannot verify that the transmit- 
ted data were received by the destination application 
process within a given number of other transmission at- 
tempts or a given time period, an error notification is 
generated to alert a user of a transmission failure. In 

io performing the receipt verification function, data are first 
placed in an outbound data queue in the outbound bro- 
ker process prior to transmission. After transmission, 
the outbound broker process listens for a receipt ac- 
knowledgment to be generated and transmitted by the 

is inbound broker process of the destination application 
process. If the acknowledgment is received within a giv- 
en number of other transmission attempts or a given 
time period, the transmitted data are removed from the 
outbound data queue and no further monitoring of this 

20 data transmission is performed. As mentioned above, 
however, if this acknowledgment is not received by the 
outbound broker process within a given number of other 
transmission attempts or a given time period, an error 
notification is generated. This error notification may then 

25 trigger an automated process that handles the error or 
alert a user to the error condition so that manual han- 
dling of the error can be accomplished. 
[0022] To configure and control the processing of 
these functions of the system and method of the pres nt 

30 invention, preferred embodiments may also include a 
management system that is connected to the commu- 
nication network. Using this management system, a us- 
er may, for example, set up communications to or from 
new application processes, remove communications 

35 from existing application processes, add. remove, or 
modify data types and formats, add, remove, or modify 
destinations for any data type, specify criteria for receipt 
acknowledgment error notification generation, and en- 
able or disable any of the conversion, routing, and re- 

-to ceipt verification functions. 

[0023] One embodiment of the system and method of 
the present invention is illustrated in more detail in FIGS. 
1-10. FIG. 1 shows an integrated processing architec- 
ture 100 that may be used to implement the present in- 

4$ vention, comprising a communication network 102, a 
management system 104, and processing systems A-D 
106. Communication network 102 is preferably a com- 
puter network that supports the TCP/IP communication 
protocol, however, any suitable network or combination 

50 of networks may also be used. Management system 
104, as mentioned above, is preferably used in archi- 
tecture 100 to enable a user to configure nnd control the 
functions of the present invention. Although architecture 
100 is illustrated as incorporating management system 

55 104, the present invention could also bo implemented 
without management system 104. Procossmg systems 
A-D 1 06 may be any suitable processing ■■ ; ^pmcnt that 
generates data. For example, any ol ossmg sys- 
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terns A-D 106 may be an inventory management sys- 
tem a financial processing system, a shipping control 
system, point of sale equipment such as cash registers 
and/or bar code scanning systems, or a warehouse 
management system. These systems 106, as well as 
management system 1 04, may be implemented on ded- 
icated hardware, a personal computer, a mainframe 
computer, or any other suitable device or devices. Each 
of systems 106 may be a unique type of system that 
executes unique software on unique hardware, or any 
number or all of systems 106 may be partially or com- 
pletely identical. Although four systems 106 are illustrat- 
ed in architecture 1 00, any number of systems 106 may 
be used in implementing the present invention. 
[0024] Referring to FIG. 2. one of processing systems 
A-D 106 is illustrated in more detail. As shown, each sys- 
tem 106 comprises application process 108, an inbound 
broker process 110, an outbound broker process 112, 
and communication software and/or hardware 114. Ap- 
plication process 108 may be any suitable software for 
execution on system 106. For example, if system 106 is 
an inventory management system, application process 
108 may be suitable inventory management software. 
Inbound broker process 110, as mentioned above, is 
used to implement portions of the functions of the 
present invention. For example, inbound broker process 
110 may perform conversion and/or receipt verification 
of data received at processing system 106. Outbound 
broker process 112. as also mentioned above, is also 
used to implement portions of the functions of the 
present invention. For example, outbound broker proc- 
ess 11 2 may perform conversion, routing, and/or receipt 
verification of data to be transmitted from processing 
system 106. Although inbound broker process 110 and 
outbound broker process 112 are illustrated as being 
separate processes that are executed on processing 
system 106, processes 110 and 112 could also be exe- 
cuted in a single process or as any number of individual 
processes that is or are executed completely on, par- 
tially on. or completely off of processing system 106. For 
example, a single inbound/outbound broker could be im- 
plemented on a separate processor connected between 
processing system 106 and communication network 
102 Lastly, communication software and/or hardware 
114 may be any suitable combination of software and/ 
or hardware that enables communication over commu- 
nication network 102. For example, communication soft- 
ware and/or hardware 114 may comprise an Ethernet 
interlace circuit card assembly and suitable driver soft- 

W3T6 

[0025] Outbound broker process 112 is illustrated in 
more detail in FIG. 3. As shown, once process 11 2 has 
begun at block 1 22, process 112 waits for and receives 
either data from source application process 108 (FIG. 
2) or a receipt acknowledgment from an inbound broker 
process 110 (FIG. 2) of another application process 108 
(FIG. 2). After data or a receipt acknowledgment is re- 
ceived at block 124. process 112 proceeds to test 126 



to determine whether a receipt acknowledgment was re- 
ceived. If at test 126 a receipt acknowledgment is de- 
termined not to have been received, a conversion proc- 
ess is performed on the received data at block 1 28. This 
5 conversion process converts the data from a format as- 
sociated with source application process 108 (FIG. 2) to 
a standard format. Once the data have been converted, 
a transmission process is performed on the data at block 
1 30. This transmission process prepares the data for 
10 transmission and transmits the data. If at test 1 26 a re- 
ceipt acknowledgment is determined to have been re- 
ceived, the corresponding transaction is recognized as 
being delivered and the associated data are removed 
from a local queue corresponding to the transaction's 
is destination at block 132. Finally, after transmitting the 
data at block 130 or deleting the transaction data from 
the local queue at block 1 32. process 1 1 2 loops back to 
block 1 24 to again wait for and receive data or a receipt 
acknowledgment. 
20 [0026] FIG. 4 illustrates the conversion process of 
block 128 of FIG. 3 in more detail. As shown, after this 
process has begun at block 1 40, the process first deter- 
mines whether data to be transmitted were rec ived 
from source application process 108 (FIG. 2) as a set of 
25 semantic assignments or as data in a generic format at 
test 1 42. As used herein, a semantic is a set of informa- 
tion that is associated with a piece of data and which 
includes a label and a set of system-specific require- 
ments for the piece of data. For example, a semantic for 
so a piece of shipping data may include a label entitled 
"to .location" that indicates that the piece of data repre- 
sents where a shipment is being sent to, and a set of 
requirements which dictate that this data may only be 
assigned values of "dock," "warehouse," "factory," and 
35 -store" on a particular system 106 (FIGS. 1-2). When 
transmitted from an application process 108 (FIG. 2), a 
semantic assignment for this piece of data may be rep- 
resented by a string such as °toJocation=dock." Data 
in a generic format may include data passed by a source 
40 application 108 (FIG. 2) in any fashion other than as a 
set of semantic assignments. For example, data for a 
shipment may be sent in a generic format as a stream 
of characters separated by a predetermined delimiter 
such as a pipe character ("I"). If the conversion process 
45 determines at block 142 that data were received from 
an application process as a set of semantic assign- 
ments, then the process parses those semantic assign- 
ments and packs the data at block 144. Otherwise, the 
process parses the data from a generic format and 
so packs the data at block 146. The data packing per- 
formed in blocks 144 and 146 may be used to remove 
unnecessary information from a piece of data and may 
include removing leading zeros from a number and re- 
moving trailing spaces from a set of characters. 
55 .[0027] Once data received from source application 
process 108 (FIG. 2) have been packed at blocks 144 
or 146, the conversion process looks for a transaction 
type corresponding to the to-be-transmiUed data in a 
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transaction database at block 148. This database is 
preferably stored locally on processing system 106 
(FIG. 2) on which outbound broker process 112 (FIG. 3) 
is being executed. If the transaction type is then deter- 
mined not to have been found at test 1 50, the conversion 
process stores the transaction name and data in an error 
queue at block 1 52 and terminates at block 154. Other- 
wise, if the transaction type is determined to have been 
found at test 150, then the corresponding transaction 
information is received from the transaction database at 
block 156. Finally, the packed data are placed in trans- 
action fields defined by the transaction information at 
block 158 and the process is completed at block 154. 
[0028] The transmission process of block 1 30 of FIG. 
3 is illustrated in detail in FIG. 5. As shown, once the 
transmission process has begun at block 160, the proc- 
ess queries the transaction parameters for the data to 
be transmitted at block 162. These transaction param- 
eters are preferably stored in a database located on the 
processing system in which outbound broker process 
112 (FIG. 3) is being executed, and preferably include 
a list of the destinations for the transaction, whether the 
transaction is a secure transaction, etc. As stated 
above, the list of destinations for the transaction may be 
based upon the type of transaction to be transmitted or 
the particular source of the transaction. Next, at test 1 64, 
the process determines whether the transaction is a se- 
cure transaction based upon these parameters, and if 
so. the transaction data are encrypted at block 1 66. After 
encryption at block 166 or if the transaction is deter- 
mined not to be a secure transaction at test 1 64, the first 
destination of the transaction is identified and a serial 
number for the transaction is obtained at block 168. 
Preferably, this serial number is selected incrementally 
for each transmission to the same destination from this 
source. Using incremental serial numbers in this way, 
allows a destination to recognize a lost transmission 
from a gap in adjacently received serial numbers from 
the same source. 

[0029] Once a destination and serial number are se- 
lected, a transmission record is built for this destination, 
the record is written to a transmission queue, and the 
record is transmitted to the destination in turn at block 
170. This transmission record may be used to identify 
the source address, the transaction type, whether the 
data are encrypted, and the date, time, and serial 
number of the transmission. The transmission record al- 
so contains the data to be transmitted. Furthermore, oth- 
er information may also be included in the transmission 
recorded depending on the requirements of the specific 
system in which the present invention is being imple- 
mented. The transmission queue to which the data are 
then written is preferably a dedicated queue that only 
contains data to be transmitted to the designated desti- 
nation. This queue is pref rably maintained on proc ss- 
ing system 1 06 (FIG. 2) on which outbound broker proc- 
ess 112 (FIG. 3) is being executed, although the queue 
may alternatively be located elsewhere as well. Once 



located in the transmission queue, the transaction data 
will then be transmitted in turn. This is preferably accom- 
plished by transmitting one transaction from each queue 
for which there are data in a cyclic fashion. Alternatively, 
s however, all or some portion of data for a single trans- 
mission queue may be transmitted prior to transmitting 
data for another queue. 

[0030] After the transaction data have been placed in 
the corresponding transmission queue at block 170, the 
10 transmission process determines whether a queue 
threshold for this queue has been passed at test 172. 
This queue threshold may include a maximum number 
of entries in the queue, or a maximum amount of time 
for a queue entry to remain in the queue. A maximum 
'5 number of entries threshold may be exceeded, for ex- 
ample, when transaction data in the transmission queue 
have not been deleted because the corresponding re- 
ceipt acknowledgments have not been received by out- 
bound broker process 112 (FIG. 3). If this threshold is 
determined to have been exceeded at test 172. an error 
notification is generated at block 174. After generating 
this notification at block 174 or if the threshold is deter- 
mined not to have been exceeded at test 172, the serial 
number for the designated destination is incremented at 
block 176. Finally, at test 180, the transmission process 
determines whether these transaction data need to be 
transmitted to any other locations, and if so loops back 
to block 168. Otherwise, the transmission process com- 
pletes at block 178. 

[0031] Referring to FIG. 6, inbound broker process 
110 of FIG.. 2 is illustrated in detail. As shown, after in- 
bound broker process 110 has begun at block 21 2, proc- 
ess 110 waits for and receives a data transmission at 
block 214. This data transmission may include transac- 
tion data that are transmitted from an outbound broker 
process 112 (FIG. 3) of another processing system 106 
(FIG. 3) or management control data that are transmit- 
ted from a management system 104 (FIG. 1). At test 
216, process 110 determines which of these data types 
was received. If at test 216 management control data 
are determined to have been received, the data are 
processed and/or stored at block 218. Preferably, in 
processing and/or storing this management control da- 
ta, the control information and configuration of both in- 
bound broker process 110 (FIG: 2) and an outbound bro- 
ker process 112 (FIG. 2) on processing system 106 
(FIG. 2) can be modified. Alternatively, a separate 
mechanism may be included in outbound broker proc- 
ess 11 2 (FIG. 2) to receive and process and/or store this 
management control data. 

[0032] If at test 216 the data received are determined 
not to be management control data, receipt processing 
is then performed on these data at block 220. Preferably, 
this receipt processing includes checking the integrity of 
the data received, generating a receipt acknowledg- 
ment for these data, and decrypting the data, if neces- 
sary. Once this receipt processing has been performed 
at block 220, the data are converted from the standard 
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format to a format corresponding to the destination ap- 
plication process 108 (FIG. 2) at block 222. Finally, the 
1. =«=c 0 ri to destination application process 108 



data are passed to destination application process 108 
(FIG 2) at block 224, and then process 110 loops back 
to block 2 1 4 to wait for and receive more data-in passing 
the data to destination application process 108 (FIG. <t), 
inbound broker process 110 (FIG. 2) may interrupt ap- 
plication process 1 08 (FIG. 2) to alert it to the presence 
of the data, or may queue the data for subsequent poll- 
ing by application process 108 (FIG. 2). 
00331 The receipt processing performed .n block 220 
of FIG 6 is illustrated in detail in FIG. 7. As shown, after 
the receipt processing of the received data has > begun 
at b.ock 232, the header message .s parsed and the 
integrity of the header and data is checked at block 234 
and test 236. If at test 236 an error is determined to exist 
in the header or data, then an error notification is gen- 
erated at block 238 and the receipt processing is termi- 
nated at block 240. Otherwise, if at test 236 no errors 
are detected in the header or data, a receipt acknowl- 
edgment is generated at block 242. Once the receipt ac- 
knowledgment is generated, the serial numbers of the 
currently received transaction and the previously re- 
ceived transaction from the same source are checked 
for a gap at block 244 and test 246. If a gap detected 
at test 246. an error notification is generated at b ock 
248 and the receipt processing is terminated at block 
240 Otherwise, if no gap is detected at test 246, the 
processing determines at test 250 whether the data are 
encrypted from the header, and if so. the data are then 
decrypted at block 252. If at test 250 the data is deter- 
mined to not be encrypted at test 250 or after the data 
have been decrypted at block 252. the transaction name 
and data are queued for conversion process.ng at block 
254, after which receipt processing is completed at 

block 240. . . ... 

,00341 The conversion process performed in block 
222 of FIG 6 is illustrated in FIG. 8. As shown, once the 
conversion processing has begun at block 260, the 
transaction name and transaction data are retneved at 
block 262 from the queue into which these items were 
olaced by block 254 of the receipt process.ng illustrated 
in FIG 7 Next, at block 264 and test 266, the conversion 
process looks for the transaction type corresponding to 
this transaction in a transaction database and deter- 
mines whether the transaction has been found, f he 
transaction type is determined not to have beer, found 
at test 266, the transaction name and data are stored in 
an error queue at block 268 and the conversion process 
is terminated at block 270. Otherwise, if the transaction 
type is determined to have been found at test 266, the 
destination application process data requirements and 
rules are retrieved at block 272 for this trans- 
action from the database. After retrieving this informa- 
tion the transaction is parsed into destination applica- 
tion process semantics at block 274. Finally the pat- 
ting rules are applied to these s^n'ics at 276 
and then the conversion process is completed at block 



270. 

f003S] A process 280 for execution in management 
system 104 of FIG. 1 is shown in FIG. 9. As illustrated, 
after process 280 has begun at block 282, an application 
5 process is selected for set up through user input or au- 
tomatically at block 284. Once an application process 
has been selected, process 280 determines at test 286 
whether inbound and outbound broker processes have 
been established on the corresponding process.ng sys- 
io tern. If test 286 determines that the broker proc esses 
have not been established, then process 280 ^stabhsh- 
es and verifies these processes at blocks 288 and 290^ 
Once the broker processes have been verified at block 
290 or if they were determined to have been established 
is at test 286, process 280 determines whether all of the 
semantics for the application process have been de- 
fined at test 292. This may be accomplished by prompt- 
ing a user, by performing checks on the applicat.on soft- 
ware or by any other suitable method. If all of the se- 
20 mantics are determined not to have been defined, then 
the semantics and corresponding attributes are defined 
at block 294. These definitions may be entered manually 
by a user of the managing system or may be performed 
under an automated process. After all the semantics 
25 have been defined at block 294 or if all the semantics 
are determined to have been defined at test 292 then 
process 280 determines whether all transactions for the 
application process have been defined at test 296. If all 
of the transactions are determined not to have been de- 
30 fined at test 296, then groups of semantics are defined 
into the required transactions at block 298. As with the 
semantics definitions, the transaction definitions may be 
performed through user interaction or by an automated 
process Once all of the transactions have been def.ned 
35 at block 298 or if all of the transactions are determined 
to have been defined at test 296, process 280 defines 
transaction routing between the source applicat.on 
process and the one or more destination appl.cat.on 
processes. As with the definition performed m blocks 
40 294 and 298, this definition may be generated through 
user input or an automated process. Finally, at block 
302 the semantic, transaction, and routing data are 
packaged and sent to each affected broker process, and 
then process 280 is completed at block 304. 
45 [0036] Thus it is seen that by performing the conver- 
sion and routing functions of the system and method of 
the present invention, only a single translator is required 
for each source and destination application process us- 
inq this system and method, changes, additions, and de- 
50 letlons of sources and destinations of data transmis- 
sions can be made without the modification or shutting- 
down of a source or destination application process us- 
ing this system and method, and that this system and 
method can be implemented in virtually any enterprise 
55 architecture without requiring that each Processing sys- 
tem of the architecture be custom bu.lt. One sk.lled the 
art will appreciate that the present invention can be im- 
plemented by other than the described embodiments. 
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dress. 

6. The method of claim 5, wherein said defining com- 
prises accepting user input that defines said known 

s data type of said data. 

7. The method of claim 5 t wherein said defining com- 
prises accepting user input that defines said source 
address of said source process. 

10 

8. The method of claim 5, wherein said defining com- 
prises accepting user input that defines said source 
format of said data. 

is 9. The method of claim 5, wherein said defining com- 
prises accepting user input that defines said stand- 
ard format of said data. 

10. The method of claim 5, wherein said defining com- 
20 prises accepting user input that defines said desti- 
nation format of said data. 

11. The method of claim 5, wherein said defining com- 
prises accepting user input that defines said rela- 
ys tionship between said destination address and said 

at least one of said known data type and said source 
address. 

12. The method of claim 5, wherein: 

30 

said determining uses said relationship in de- 
termining said destination address; and 
said relationship relates said destination ad- 
dress to both said known data type and said 
35 source address. 



which are present d for purposes of illustration and not 
of limitation, and th present invention is limited only by 
the claims that follow. 



Claims 

1. A method of communicating data of a known data 
type from a source process to a destination proc- 
ess, the method comprising: 

receiving said data in a source format from said 
source process: 

converting said data from said source format to 
a standard format; 

determining a destination address based upon 
at least one of said known data type and a 
source address that is associated with said 
source process: 

transmitting said data in said standard format 

with said destination address: 

receiving said data transmitted in said standard 

format at said destination address: 

converting said data in said standard format to 

a destination format: and 

transmitting said data in said destination format 

to said destination process. 

2. The method of claim 1 , further comprising: 

when said data transmitted in said destination 
format is received at said destination process, 
generating an acknowledgment of receipt of 
said data; and 

notifying a user of an error upon an occurrence 
of at least one of a specified number of other 
transmission attempts and an absence of said 
acknowledgment of receipt within a given time 
period. 

3. The method of claim 1 , wherein each of said source 
format, said standard format, and said destination 
format are different. 

4. The method of claim 1 , wherein l 

said source format and said destination format 
are identical: and 

said source format and said destination format 
are different from said standard format. 

5. The method of claim 1 , further comprising, prior to 
said receiving of said data in said source format, 
defining at least one of said known data type, said 
source address, said source format, said standard 
format, said destination format, and a relationship 
between said destination address and said at least 
one of said known data type and said source ad- 



1 3. The method of claim 5, wherein: 

said determining uses said relationship in de- 
termining said destination address; and 
said relationship relates said destination ad- 
dress to said source address without relating 
said destination address to said known data 
type. 

4S . _ - - - - 

1 4. The method of claim 5, wherein: 

said determining uses said relationship in de- 
termining said destination address: and 
50 said relationship relates said destination ad- 

dress to said known data type without relating 
said destination address to said source ad- 
dress. 

55 15. The method of claim 1 , wherein said converting of 
said data from said standard format to said destina- 
tion format comprises selecting said destination for- 
mat from a plurality of available destination formats 
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based upon said known data type of said data. 

16. The method of claim 1 . wherein said converting of 
said data from said standard format to said destina- 
tion format comprises selecting said destination for- 
mat from a plurality of available destination formats 
based upon said destination address transmitted 
with said data in said standard format. 

17. A system for communicating data of a known data 
type from a source process to a destination proc- 
ess, the system comprising: 

a source receiver that receives said data in a 
source format from said source process: 
a source translator that converts said data from 
said source format to a standard format: 
an addressing mechanism that determines a 
destination address based upon at least one of 
said known data type and a source address that 
is associated with said source process: 
a source transmitter that transmits said data in 
said standard format with said destination ad- 
dress: 

a destination receiver that receives said data 
transmitted in said standard format at said des- 
tination address: 

a destination translator that converts said data 
in said standard format to a destination format: 
and 

a destination transmitter that transmits said da- 
ta in said destination format to said destination 
process. 

18. The system of claim 17. further comprising: 

an acknowledgment generator that generates 
an acknowledgment of receipt of said data 
when said data transmitted by said destination 
transmitter is received at said destination proc- 
ess; and 

a notifier that notifies a user of an error upon an 
occurrence of at least one of a specified 
number of other transmission attempts and an 
absence of said acknowledgment of receipt 
within a given time period. 

19. The system of claim 17, wherein each of said 
source format, said standard format, and said des- 
tination format are different. 

20. The system of claim 17, wherein: 

said source format and said destination format 
are identical: and 

said source format and said destination format 
are different from said standard format. 



21 . The system of claim 1 7, further comprising a system 
manager that, prior to said data in said source for- 
mat being received by said source receiver, defines 
at least one of said known data type, said source 
5 address, said standard format, said destination for- 
mat, and a relationship between said destination 
address and said at least one of said known data 
type and said source address. 

10 22. The system of claim 21 , wherein said system man- 
ager accepts user input that defines said known da- 
ta type of said data. 

23. The system of claim 21 , wherein said system man- 
is ager accepts user input that defines said source ad- 
dress of said source process. 



24. The system of claim 21 , wherein said system man- 
ager accepts user input that defines said source f or- 
20 mat of said data. 



25. The system of claim 21 . wherein said system man- 
ager accepts user input that defines said standard 
format of said data. 

26. The system of claim 21 . wherein said system man- 
ager accepts user input that defines said destina- 
tion format of said data. 



25 



30 27. The system of claim 21 , wherein said system man- 
ager accepts user input that defines said relation- 
ship between said destination address and said at 
least one of said known data type and said source 
address. 



35 



40 



28. The system of claim 21, wherein: 

said addressing mechanism uses said relation- 
ship in determining said destination address: 
and 

said relationship relates said destination ad- 
dress to both said known data type and said 
source address. 



45 29. The system of claim 21 , wherein: 

said addressing mechanism uses said relation- 
ship in determining said destination address; 
and 

so said relationship relates said destination ad- 

dress to said source address without relating 
said destination address to said known data 
type. 

55 30. The system of claim 21 , wherein: 

said addressing mechanism uses said relation- 
ship in determining said destination address; 
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and 

said relationship relates said destination ad- 
dress to said known data type without relating 
said destination address to said source ad- 
dress. 5 

31. The system of claim 17, wherein said destination 
translator comprises a selecting mechanism that 
selects said destination format from a plurality of 
available destination formats based upon said io 
known data type of said data. 

32. The system of claim 17, wherein said destination 
translator comprises a selecting mechanism that 
selects said destination format from a plurality of is 
available destination formats based upon said des- 
tination address transmitted with said data in said 
standard format. 

20 
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implemented in virtually any enterprise architecture 
without requiring that each processing system of the ar- 
chitecture be custom built. These conversion and rout- 
ing functions are performed by first receiving data to be 
transmitted in a source format from a source application. 
This data are then converted from the source format to 
a standard format. Next, one or more destinations are 
identified in a database using a transaction type corre- 
sponding to the data and/or the address of the source 
application. After identifying the one or more destina- 
tions, a copy of the data is transmitted to each and the 
data are then converted from the standard format to a 
destination format. Lastly, this converted data are 
passed to the destination process. 
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